home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / NextAnswers / 1230_loadable_kernel_server_and_breakpoints.rtf < prev    next >
Text File  |  1995-06-12  |  3KB  |  63 lines
  1. {\rtf0\ansi{\fonttbl\f0\fnil Times-Roman;\f1\fmodern Courier;\f2\fmodern Ohlfs;}
  2. \paperw11720
  3. \paperh8340
  4. \margl120
  5. \margr120
  6. {\colortbl;\red0\green0\blue0;\red84\green84\blue84;\red83\green83\blue83;}
  7. \pard\tx1140\tx2300\tx3440\tx4600\tx5760\tx6900\tx8060\tx9200\tx10360\tx11520\f0\b0\i0\ulnone\fs28\fc0\cf0 Q:  When I run gdb (Release 3) or kgdb (Release 2) on my loadable kernel server, the slave system doesn't stop at the breakpoints I've set.   What am I doing wrong?  \
  8. \
  9. Q:  The symbols in my kernel server seem to have addresses that are relative to the origin of the kernel server, not the origin of the kernel.   What am I doing wrong?   Are these related?\
  10. \
  11. A:  When you compile a kernel server with kl_ld, it produces a 
  12. \b relocatable
  13. \b0  object module.     This  module has not been linked against the kernel, and the addresses of its symbols start at 0.  When you invoke kl_util -a, it edits the server's links against the currently running kernel,  and produces a 
  14. \b loadable
  15. \b0  module, with addresses that reflect its actual location in the kernel.   \
  16. \
  17. Normally, the loadable module is simply loaded into the kernel, and not copied into the file system.    However, if you  invoke kl_ld with the 
  18. \b -d 
  19. \b0 option,  then when you later execute kl_util -a, the loader will leave behind a copy of the loadable object file (-d option in bold face below):\
  20. \
  21.         \
  22.  
  23. \f1\fs24\fc1\cf1     mysystem% kl_ld -n myserver -l Load_commands -u \\\
  24.         Unload_Commands -i instance_variables \\\
  25.         
  26. \b -d  myserver_loadable \\
  27. \b0 \
  28.         -o myserver_reloc \\\
  29.         myserver_object_file.o other_object.o\
  30.     mysystem% ls *reloc *loadable\
  31.         
  32. \i myserver_reloc
  33. \i0  \
  34.     mysystem%\
  35.     \
  36.     \
  37.     mysystem% kl_util -a myserver_reloc\
  38.     mysystem% ls *reloc *loadable\
  39.         
  40. \i myserver_reloc myserver_loadable
  41. \i0 \
  42.     mysystem%\
  43.  
  44. \f0\fs28\fc0\cf0 \
  45. \
  46. (Note that
  47. \fc1\cf1  you must specify the _loadable suffix as part of <name>.   The system doesn't do that for you.)\
  48. \
  49. It is the _loadable module against which you must execute gdb(kgdb), not the _reloc object.\
  50. \
  51. If you run gdb(kgdb) against the relocatable module, or against the wrong loadable module, the addresses seen are incorrect, and breakpoints do not work.\
  52. \
  53. If you have any question as to whether the module your using is the right one, you can look at its addresses with the nm command, and compare them to the addresses of the same symbols in the kernel you're debugging.   They should be the same.\
  54.  
  55. \pard\tx520\tx1060\tx1600\tx2120\tx2660\tx3200\tx3720\tx4260\tx4800\tx5320\fc1\cf1 \
  56.  
  57. \pard\tx1140\tx2300\tx3440\tx4600\tx5760\tx6900\tx8060\tx9200\tx10360\tx11520\fc0\cf0 \
  58. QA722\
  59.     \
  60. Valid for 2.0, 3.0\
  61. \
  62.  
  63.